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ABSTRACT 


Two  programming  paradigm*,  logic  programming  and 
functional  programming,  ara  diacuaaad  in  datail  with 
emphaaia  on  the  particular  advantage*  and  diaadvantagea  of 
each  paradigm. 

The  integration  of  theae  two  programming  paradigma  la 
explored  baaed  on  the  notion  that  declarative  aorta  of 
knowledge  (facta  and  logical  relationahlpa)  ahould  be 
expreaaed  in  a  declarative  way,  and  that  procedural  aorta  of 
knowledge  (manipulation,  control,  and  utilization  of 
knowledge)  ahould  be  expreaaed  in  a  procedural  way.  Toward 
thia  end,  the  conceptual  framework  for  an  integrated 
language  ia  eatabliahed,  and  the  baaic  feature*  of  the 


language  are  outlined. 
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I.  INTRODUCTION 

A.  PROGRAMMING  LANGUAGE  DESIGN 

Prograaaing  language  design  rapraaanta  both  an  effort  to 
provide  the  neceaaary  interface  with  the  hardware  of  the 
coaputer  and  an  effort  to  better  capture  the  ideas  of  the 
prograaaer.  Aa  higher  order  prograaaing  languages  evolve,  a 
key  factor  in  each  language  designed  is  the  level  of  ab¬ 
straction  afforded  the  prograaaer.  Current  conventional 

languages  have  reaoved  the  prograaaer  froa  the  hardware 
level  of  the  aachine.  For  instance,  instead  of  being  con¬ 
cerned  with  which  registers  to  use,  the  prograaaer  can  be 
aore  concerned  with  solving  the  problea  at  hand.  For 
certain  classes  of  probleas,  this  higher  level  of  abstrac¬ 
tion  increases  the  seaantic  power  of  the  language  and  better 
captures  the  problea  solving  concepts  of  the  prograaaer. 
The  evolution  of  prograaaing  language  design  has  resulted  in 
solutions  to  a  broader  class  of  probleas  and  even  new 
approaches  toward  the  solution  of  presently  unsolved 
probleas. 

B.  PROBLEM  COMPLEXITY 

The  features  of  the  language  are  the  tools  with  which 
the  prograaaer  tackles  a  host  of  coaplex  probleas.  As  the 
problea  coaplexity  increases,  the  Banner  in  which  one  works 


toward  a  aolution  can  ba  af  fact  ad  by  tha  tool  or  toola 
availabla.  Conaldar  tha  analogy  of  an  autoaobila  mechanic 
working  on  an  automobile  angina;  a  aimpla  tuna-up, 
adjuatment,  or  email  part  raplacamant  can  ba  performed  with 
aimpla  handtoola  and  davicaa.  However,  if  tha  problem  la 
more  complex,  aay  involving  tha  cylindara,  camahaft,  or 
drive  train,  than  tha  mechanic  cannot  aolve  auch  problema 
with  aimpla  toola.  Tha  aolution  now  raquiraa  more  advanced 
toola  like  hydraulic  lifta,  pneumatic  toola,  and  preciaion 
inatrumanta.  In  fact,  without  more  advanced  toola,  the  30b, 
if  atill  poaaibla,  ia  aolvad  through  improvisation  with  the 
aimpler  toola  and  raaulta  in  a  laaa  efficient  and  impreciae 
aolution. 

C.  SAPIR-WHORF  HYPOTHESIS 

Similarly,  tha  featurea  of  tha  programming  language  can 
effect  tha  manner  in  which  tha  programmer  approaches  the 
aolution  to  a  particular  problem.  Thia  can  be  conaidered  an 
application  of  tha  controvaraial  Sapir-Whorf  hypothesis 
which  originated  in  linguistic  theory  [Ref .  13 .  Assuming 
thia  hypothesis,  tha  programmer  attempting  to  solve  complex 
problems  with  a  limited  programming  language  cannot  realize 
his  full  problem  solving  potential  and  must  improvise  with 
the  available  language  featurea  to  work  toward  an  acceptable 


aolution 


D.  NON- CONVENTIONAL  PROGRAMMING  LANGUAGES 

Conventional  programming  languagaa  do  not  offer  the 
programmer  a  very  high  level  of  abstraction,  have  a 
reatrictive  "word-at-a-time"  [Ref.  5:  p.  404]  programming 
style,  and  reault  in  what  Backua  refera  to  as  an 
Mintellectual  bottleneck"  CRef .  31 .  The  sequential  nature 
of  theae  imperative  languagea,  through  uae  of  assignment 
ststements  to  altar  memory,  results  in  a  von  Neumann  "mind 
set”,  and  placea  limitations  upon  the  level  of  abstraction 
available  to  the  programmer.  Efforts  to  provide  more 
semantic  power  to  theae  languagea  has  resulted  in  the 
development  of  the  Ada  CRef.  6]  programming  language.  This 
very  large  and  very  complex  language  provides  increased 
semantic  power  at  the  cost  of  simplicity,  clarity  of 
understanding,  and  programmer  mastery  of  his  tool  CRef.  6] . 

Non-conventional  programming  languages,  on  the  other 
hand,  offer  a  break  from  the  von  Neumann  mind  set  and  help 
the  programmer  approach  and  solve  problems  from  new 
perspectives.  Such  non-conventional  programming  languages 
are  illustrated  by  PROLOG  CRef.  2,7],  Backus'  FP  language 
CRef.  31 ,  and  SMALLTALK  CRef.  4] .  Each  of  these  languages 
represents  an  implementation  of  a  particular  programming 
language  paradigm,  namely,  logic  programming,  functional 
programming  (applicative  programming  with  emphasis  on 
functions  as  arguments),  and  object-oriented  programming, 
respectively.  Issues  such  as  semantics,  computational 
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power,  parallelism,  aide  ef facta,  flexibility,  simulation, 
and  knowledge  repreaentation  exeaplify  some  of  the  baaia  for 
development  of  language  deaign  in  each  of  theae  programing 
paradigaa. 

E.  RESEARCH  FOCUS 

With  theae  iaauea  in  aind,  two  programming  paradigms, 
logic  programming  and  functional  programming,  are  discussed 
in  detail.  The  emphasis  of  the  discussion  will  be  in  terms 
of  the  particular  advantages  or  disadvantages  of  each 
programming  paradigm,  often  exemplified  by  the  PROLOG  or 
"pure"  LISP  implementation.  The  focus  of  this  study  will  be 
toward  the  development  of  a  theoretical  foundation  for  the 
design  of  an  integrated  programming  language  which,  of 
course,  maximizes  the  advantages  of  both  paradigms  and 
minimizes  their  disadvantages.  Such  an  integrated  language 
should  broaden  the  scope  of  the  programmer's  problem  solving 
capability  by  providing  a  tool  that  is  both  semantically  and 
computationally  powerful,  and  offers  improved  control 
characteristics . 


degree  rests  with  those  portions  of  PROLOG  which  embody  the 
festures  of  predicate  logic.  For  example,  the  use  of 
'assert'  and  'retract'  predicates  in  the  language  allows  the 
assertion  and  retraction  of  axioms  based  upon  conditions 
within  the  logic  program. 

This  violates  the  principle  of  predicate  logic 
that  each  assertion  is  an  independent  truth.  Therefore,  in 
the  resolution  process,  there  are  different  sets  of  axioms 
at  different  points  in  time  CRef.  32.  This  dependence  of 
some  axioms  and  the  addition  or  deletion  of  others  diverges 
from  the  notion  of  separation  of  logic  and  control.  In 
order  to  provide  the  programmer  with  a  means  to  alter  a 
database  of  facts,  the  advantages  of  separation  of  logic  and 
control  (discussed  above)  are  sacrificed. 

F.  SUMMARY 

The  logic  programming  paradigm  offers  the  programmer  a 
high  level,  non-procedural  approach  to  problem  solving 
enhanced  by  the  simple  semantics  of  Horn  clauses.  The 
resolution  of  goal  statements  and  the  unification  of 
variables  within  that  goal  is  at  a  level  below  that  of  the 
programmer.  Additionally,  the  inherent  capability  to 
separate  the  logic  of  the  problem  solution  from  the  factors 
which  control  the  solution,  allows  the  programmer  to  focus 
attention  upon  the  logical  relationships  of  the  problem 
solution  and  program  correctness. 


automata  and  systaaa  programming  become  auch  aore  difficult 
to  aolva. 

4.  Iapleaentation  Considerations 

The  aoat  notable  iapleaentation  of  logic  programming 
la  PROLOG,  and  the  drawbacks  noted  here  are  factors  that 
affect  efficiency  or  sacrifice  some  of  the  power  of  the 
language  in  favor  of  more  efficient  execution. 

a.  Backtracking  and  Efficiency 

As  mentioned  earlier,  backtracking  through  a 
very  large  search  space  can  be  very  costly  to  the  search 
strategy,  yet,  for  auch  resolution-type  systems  as  PROLOG, 
it  is  very  necessary.  Unfortunately,  it  is  this  vast  amount 
of  time  spent  backtracking  by  the  PROLOG  interpreter  that 
makes  solutions  to  goal  statements  very  slow  in  coming. 

b.  Unification 

In  order  to  regain  some  of  this  lost  efficiency, 
many  PROLOG  implementations  do  not  provide  full  unification. 
For  instance,  the  resolution  process  would  allow  the 
unification  of  f<x,x)  with  f<y,  g<y>>,  and  would  bind  x  to 
g<x>  [Ref.  73.  The  problem,  of  course,  is  that  the  attempt 
to  prune  the  search  tree  allows  circularity  and  the 
generation  of  infinite  loops. 

c.  Assertion/Retraction 

In  the  vein  of  predicate  logic  problem  solving, 
there  have  been  claims  that  PROLOG  programs  have  no  side 
effects  [Ref.  73.  To  some  degree  this  is  true,  and  that 
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not  halt  on  a  non-thtorea  CRef .  18:  p.  1393 .  Such 

procedures  are  said  to  be  semidecidable . 

2.  S9Pfrlfl3torlql-gxplg3*PTl 

All  resolution  strategies  are  subject  to  the  problem 
of  combinatorial -explosion,  since  the  search  trees  generated 
can  grow  very  unpredictably  CRef .  19:  p.  2293 .  Somewhat 

akin  to  the  halting  problem,  it  means  that  a  success  for  the 
proof  of  an  actual  theorem  may  be  prevented  due  to  the 
tremendous  size  and  shape  of  the  search  apace. 

3.  Axlomatlze  All  Knowledge? 

The  use  of  logic  programming  toward  the  solution  of 
all  problems  leads  to  the  restriction  that  all  knowledge 
associated  with  the  problem  must  be  embodied  in  axioms 
CRef.  19:  p.  2313.  Such  a  process  might  require  an 

enormous  effort. 

a.  Heuristics 

A  considerable  portion  of  this  effort  can  be 
attributed  to  the  fact  that  there  is,  as  mentioned  above,  no 
provision  for  heuristics  in  the  knowledge  representation. 
Therefore,  such  notions  as  best,  next  best,  worst,  etc. 
resist  representation  in  logic,  and  make  a  logical  statement 
of  the  problem  difficult  or  impossible. 

b.  No  Expression  of  State 


Another  drawback  of  logic  programming  is  the 
absence  of  a  method  for  representing  state  transitions. 
Without  such  representation  many  problems  embodied  in  finite 


knowledge,  it  is  important  to  considsr  whether  predicate 
logic  provides  sdsqusts  support  for  reasoning  about  that 
knowledge  [Ref.  18:  p.  1391 . 

1.  Undecldabllltv  and  the  Halting  Problem 

A  major  drawback  of  predicate  logic  is  the  absence 
of  a  decision  mechanism  for  dealing  with  the  knowledge  that 
can  be  inferred  from  stated  assertions.  Without  euch  a 
mechanism,  the  resolution  procedure  blindly  searches  for  a 
solution. 

Pure  logic  does  not  allow  the  expression  of 
heuristics,  which  hinders  the  search  for  a  path  to  a 
solution  during  the  resolution  process  CRef .  19:  p.  2311 . 
Therefore  the  resolution  strategy  may  allow  numerous 
unnecessary  and  divergent  paths  to  be  taken  during  the 
search.  This  can  become  a  grossly  inefficient  method  of 
search. 

Additionally,  given  a  goal  statement,  using 
resolution  to  reason  backward  will  produce  a  proof  if  the 
proposed  goal  statement  is,  in  fact,  a  theorem  based  upon 
the  assertions  and  clauses  in  the  logic  program.  However, 
there  is  no  guarantee  that  such  a  search  will  terminate  if 
there  is  no  proof  CRef.  19:  p.  2291.  This  is  a  version  of 
the  halting  problem  and  is  one  that  the  AI  community  has 
come  to  live  with  in  their  pursuit  of  proof  methods,  being 
content  with  a  method  that  proves  theorems  even  if  it  may 
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interrelationship  of  those  control  structures  with  the 
actual  logic  of  tha  program  CRaf.  5:  p.  5103. 

Logic  programming ,  on  tha  othar  hand,  allows  a  much 
graatar  aaparation  of  logic  and  control.  Sinca  tha  order  of 
tha  clauses  of  a  logic  program  has  no  effect  upon  the 
correctness  of  tha  program,  tha  meaning  of  tha  program  ia 
tied  to  tha  logical  relationship  of  the  program  clauses,  not 
tha  order  in  which  they  are  executed  CRaf.  2,  5,  81 . 

This  separation  of  logic  and  control  introduces  the 
notion  of  separate  analyaia.  Logical  analysis  ia  a  concern 
for  tha  correctness  of  tha  program,  whereas,  control 
analysis  ia  a  concern  with  tha  efficiency  of  the  program 
CRaf.  5,  83 . 

An  obvious  advantage  of  this  separation,  with  regard 
to  logic  programming,  ia  that  tha  programmer  can  focus 
attention  upon  the  details  of  tha  logic  component  when 
concerned  with  program  correctness.  Once  a  correct  program 
has  been  established,  tha  programmer  can  than  focus  upon  the 
control  component  for  efficiency  considerations.  This 
disjoint  analysis  simplifies  tha  programmer's  task  by 
removing  tha  previously  dependant  relationships  between  the 
two  components. 

E.  DISADVANTAGES 

Although  predicate  logic  offers  some  advantages  to  the 
programmer  in  terms  of  representation  of  certain  kinds  of 
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1.  Mon -Procedural 

The  notion  of  a  non -procedural  language  la  one  In 
which  the  features  of  the  language  allow  the  programmer  to 
concentrate  more  on  "whet"  the  program  will  do  and  not  on 
“how"  It  will  be  done  CRef.  5:  p.  4991.  The  goal-directed 
nature  of  logic  programming  embodiea  thia  notion,  in  that 
the  programmer  expreaaea  the  facta,  in  clause  fora,  which 
assert  the  existence  of  the  desired  result  CRef.  3:  p.  5001 . 
The  construction  of  the  desired  result,  then,  is  based  upon 
the  resolution  process  of  the  logic  programming  language  and 
removes  the  burden  of  "how"  it  will  be  done  from  the 
programmer. 

2.  SllBil 

Much  of  the  power  behind  the  semantics  of 
programming  rests  with  the  notions  of  truth  and  inference 
[Ref.  181 .  Assertions  within  the  logic  program  are  accepted 
as  truth,  and  the  clauses  within  the  program  are  facts  that 
allow  inferences  to  be  made  baaed  upon  those  assertions. 

3.  Separation  of  Logic  and  Control 

Closely  related  to  the  non-procedural  notion  of 
programming  is  the  notion  of  a  logic  component  and  a  control 
component  within  the  language  CRef.  83 .  The  control 
structures  of  conventional  languages  determine  the  order  in 
which  actions  within  the  program  taka  place.  The  fact  that 
statements  within  that  program  must  be  executed  in  a 
specified  order  to  ensure  correctness  illustrates  the 
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for  aatching  CRaf.  121.  Thia  procaaa  ia  cal lad  backtracking 
and  tha  noda  at  which  backtracking  atopa  ia  cal lad  a 
backtracking  point.  Tha  aaarch  contlnuaa  from  tha 
backtracking  point  purauing  tha  unaaarchad  altarnativaa.  A 
auccaaa  raquiraa  that  every  path  of  tha  proof  traa  and  with 
tha  aapty  clauaa  CRaf.  123 . 

For  example,  in  Figura  2.2(a),  tha  laaf  0  can  ba 
raaolvad  with  tha  aapty  clauaa,  but  tha  laaf  E  cannot, 
aincathara  ara  no  clauaaa  within  tha  logic  program  that  have 
a  head  to  match  it.  Tharafora  the  ayatem  muat  backtrack  to 
noda  B  ainca  an  alternative  choice  within  the  aaarch  tree 
(aaa  label  (3),  Figura  2.1)  ia  atill  available.  That  choice 
ia  depicted  by  tha  proof  traa  in  Figure  2.2(b). 

Thia  backtracking  ia  nacaaaary  bacauaa  of  the  non-* 
datarminiatic  character iatica  of  tha  raaolution  of  aubgoals. 
Yet  it  ia  aaay  to  aaa  that  fairly  large  and  complex  programa 
would  require  conaidarable  backtracking. 

D.  ADVANTAGES 

Logic  programming  off era  aeductive  advantagea  when 
dealing  with  certain  claaaaa  of  problema.  Idaaa  of  logic 
have  matured  for  centuriea  and  have  a  concise  and 
univaraally  undaratood  aemantica.  For  bodiea  of  knowledge 
that  can  ba  rapreaantad  in  a  logical  form,  logic  programming 
offara  a  maana  to  prove  thinga  about  that  body  of  knowledge 


(Ref.  203 


proof  troo  CRof .  123 .  A  proof  troo  is  generated  for  each 
noda  in  the  March  tree.  It  ia  an  AMD- tree  whara  tha  root 
ia  tha  original  goal  and  tha  laavaa  ara  tha  corraaponding 
aubgoala  of  tha  aaarch  traa  CRaf .  123 .  Tha  proof  traaa  for 
nodaa  <--  D,E,C  and  < —  F.C  ara  illuatratad  in  figure  2.2 


A 

/\ 

/  \ 

✓  V 
B  \ 

/\  \ 

/  \  \ 

/  S  \ 

DEC 


A 

/\ 

/  \ 

/  \ 

B  \ 

I  \ 

I  \ 

I  \ 

F  C 

<b> 


Figure  2.2  Proof  Traaa 


During  tha  raaolution  procaaa,  if  a  leaf  cannot  ba 
unified  or  raaolvad  with  tha  head  of  another  definite  clauaa 
within  tha  logic  program ,  than  a  portion  of  tha  traa  ia 
araaad.  That  portion  ia  from  tha  unreaolvable  leaf  back  to 
tha  aoat  recant  noda  that  haa  not  exhauated  ita  potential 


atataaant.  Each  adga  of  tha  traa  la  labalad  by  tha  indax  to 
tha  particular  clauaa  of  tha  logic  program  (above)  that  waa 
uaad  in  tha  raaolution  procaaa  baaad  upon  tha  aalaction 
coaponant  pravioualy  daacribad.  Tha  aaarch  coaponant 
prograaaaa  through  tha  antira  traa  until  aithar  tha  empty 
clauaa  ia  found  or  tha  antira  traa  ia  aearchad  ERef .  12] . 
Although  tha  unifying  aubatitutiona  ara  ignorad  hare,  thoae 
aubatitut iona,  aada  along  a  auccaaaful  path,  yiald  an  anawer 
for  tha  goal  atataaant. 


Figura  2.1  Saarch  Spaca  Dapictad  aa  a  Traa 

Zn  ordar  to  avoid  tha  radundancy  of  rapaatad 
aubgoala  in  tha  aaarch  traa,  aany  PROLOG  ayataaa  conatruct  a 


search  apace  or  because  of  finite  paths  that  do  not  laad  to 
tha  aapty  clause  CRaf .  163 . 

3.  PROLOG  Example 

Tha  aalaction  coaponant  of  PROLOG  providaa  a  rule 
that  always  aalacta  tha  laftaoat  litaral  CRaf.  3,  163 . 
Therefore,  tha  nagativa  literals  of  a  clause  must  be  ordered 
and  fixed,  and  only  those  search  spaces  (or  developing 
trees)  can  be  lap lament ad  CRaf.  163  .  Tha  search  component 
in  PROLOG  provides  s  depth-first  strategy  with  tha  leftmost - 
descendant  first  (derived  by  tha  above  selection  rule) .  The 
ordering  of  descendants  is  determined  by  tha  ordering  of  the 
definite  clauses  within  the  logic  program. 

Consider  the  following  logic  program  (ignoring  the 
structure  of  the  clauses  and  the  unifying  aubstitutiona) 
CRaf.  123: 

(1)  A  <--  B,  C 

(2)  B  <--  D,  E 

(3)  B  <--  F 

(4)  C 

(5)  D 

(6)  F  <--  G 

(7>  F 

Given  the  goal  statement  < - -  A,  the  search  space  for 
resolving  this  goal  is  depicted  as  s  tree  in  Figure  2.1 
CRaf.  123.  This  search  tree  is  an  OR-tree  whose  nodes  are 


possible  goals  that  may  occur  during  resolution  of  the  goal 


-A,  V...V  -A  ,  and  that  tha  subgoal  baing  raaolvad  ia  -A., 
in  i 

Sinca  tha  haad  of  the  clause  ia  tha  poaitiva  literal,  tha 
unification  of  tha  aubgoal  and  tha  dafinita  clauaa  raaolvaa 
tha  litaral  ,  and  raplacaa  it  with  tha  body  of  tha  clauaa 
CRaf .  10,  16] .  Thia  darivation  ia  possible,  of  couraa,  only 
if  aoaa  ganaral  aubatitution  function,  napping  variablaa  to 
tarna,  nakaa  tha  aubgoal  and  tha  haad  of  tha  dafinita  clause 
identical  CRaf .  10] . 


Pradicata  logic  ia  non-datarninlstic  in  that  the 
unification  procaaa  follows  a  pattern  matching  scheme  for 
resolution  of  aubgoala  and  aora  than  one  definite  clause  may 
have  a  haad  that  will  natch  CRaf.  10,  12] .  Therefore,  a 
resolution  procedure  like  LUSH  requires  a  selection 
component  and  a  search  component  CRaf.  16],  where  the 
selection  component  ia  the  rule  to  determine  the  search 
space,  and  tha  search  component  is  the  strategy  whereby  that 
apace  ia  searched.  This  search  space  can  be  thought  of  as  a 
tree  with  tha  goal  statement  as  the  root  and  descendant 
nodes  determined  by  the  selection  component.  The  paths  of 
thia  tree  are  than  traversed  according  to  a  strategy  given 
by  tha  search  component. 

Such  a  non-deterministic  system,  then,  requires 
somewhat  restrictive  selection  and  search  components  because 
of  tha  possibility  of  an  infinite  number  of  paths  in  the 


C.  GOAL  SATISFACTION 

A  logic  program  conaiata  of  a  nuibar  of  thaaa  Horn 
clauaea,  aa  axioma,  upon  which  tha  attaaptad  aatiaf action  of 
a  particular  goal  ia  baaad  CRef.  123.  An  important  point 
hara  ia  that  thaaa  axioaa  ara  uaar  dafinad  and  baaically 
provida  tha  ayataa  intarpratar  with  tha  facta  raquirad  to 
dataraina  whathar  a  givan  goal  ia  aatiafiabla. 

1.  Raaolutlon_and_ Unification 


A  logic  programming  intarpratar  attampta  to  aolve  a 
particular  goal  atatamant  by  raaolving  any  aubgoala  within 
tha  atatamant  with  tha  haada  of  definite  clauaea  of  the 
logic  program.  Since  the  reaolution  proceaa  ia  one  of  proof 
by  refutation,  a  goal  ia  aatiafiable  if  the  empty  clauae 
(contradiction)  can  be  derived.  During  the  derivation 
certain  bindinga  for  variablea  may  be  made  which  become  the 
aolution  for  the  given  goal  atatement  [Ref.  12] . 

There  are  aeveral  algorithma  [Ref.  13,  141  for 
performing  auch  unif icationa,  the  foundation  of  which  ia 
deacribed  by  Kowalaki  CRef.  9]  and  detailed  by  Hill  CRef. 
IS],  where  he  namea  the  proceaa  LUSH  (linear  reaolution  with 
gnreatricted  Selection  for  lorn  clauaea) . 

The  LUSH  rule  of  inference  takea  a  given  goal 
atatement  A^,...,An  and  attempta  to  reaolve  a  aubgoal  A ^ 
with  a  definite  clauae  within  the  logic  program  that 
contalna  an  identical  fora  of  A^  aa  the  head  of  the  clauae. 
Recall  that  the  actual  fora  of  the  goal  atatement  ia 


A  logic  program  consist*  of  tha  axpllcit  us#  of  Horn 
clauses  in  tha  process  of  goal  satisfaction.  Both  Horn 
clauses  and  the  process  of  goal  satisfaction  are  described 
below.  Additionally,  the  advantages  and  disadvantages 
afforded  the  programmer  by  using  logic  programming  are 
detailed. 

B.  HORN  CLAUSE 

A  Horn  clause  is  a  subset  of  the  full  predicate  logic 
system  that  is  quantifier-free  and  contains  at  most  one 
positive  literal.  It  is  the  preferred  logical  formula  in 
the  expression  of  logic  programs.  Horn  clauses  can  be 
represented  by  both  the  logical  fora,  where  means 

negation,  and  the  standard  convention,  <head>  <--  <body>, 
called  a  definite  clause.  The  following  four 

classifications  of  clauses  are  illustrated  by  both: 

1)  Assertion  (only  one  positive  literal) 

B  or  B  < — 

2>  Declaration  (one  positive  literal  and  one  or  more 
negative  literals) 

B  V  -A  V...V  -A  or  B  <--  A,,...,A 

in  in 

3)  Denials  (no  positive  literals) 

-A,V...V  -A  or  < —  A.,..., A 

In  1'  n 

4)  Contradiction  (the  empty  clause) 


0 


or 


<-- 


II 


A.  BACKGROUND 

The  foundation  for  tha  davalopaant  of  a  prograaaing 
languaga  baaad  upon  tha  rigora  of  pradicata  logic  aaaaa  to 
hava  grown  out  of  aar ly  attaapta  to  automata  thaoraa  proving 
[Raf.  5,  7,  113  and  haa  aubaaquantly  baan  bolatarad  by  tha 
daaanda  of  tha  artificial  intalliganca  <AI>  community  in  an 
effort  to  liva  up  to  thair  rathar  ambitioua  nama.  Hewitt' a 
PLANNER  CRef .  11],  a  languaga  daaignad  for  thaoram  proving 
and  robot  modal  manipulation,  utilizad  auch  concapta  aa 
backtracking  and  a  databaaa  of  aaaertiona  CRef.  7],  which 
would  later  be  embraced  by  tha  daaignara  of  PROLOG.  The 
theoretical  foundation  for  programming  in  logic,  however,  ia 
probably  beat  deacribad  in  Kowalaki'a  work  CRef.  8,  9,  10] . 
In  particular,  hia  paper  in  tha  Communicationa  of  the  ACM 
CRef.  8],  though  concerned  with  pradicata  logic  aa  a  tool 
for  algorithm  analyaia,  introducaa  tha  aeparation  of  the 
logic  and  control  componenta* of  an  algorithm  and  atrongly 
auggeata  tha  uaefulnaaa  of  thia  concept  in  programming 
languagea.  Additionally,  Kowalaki  dafinea  tha  aemantica  of 
predicate  logic  programa  CRef.  9],  in  a  collaboration  with 
van  Emden,  regarding  proof  theory  and  model  theory. 
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Disadvantages  ssan  to  ariss  from  ths  fact  that  all 


knowledge  is  not  declarative  in  nature  and  does  not  lend 


III.  FUNCTIONAL  PROGRAMMING 


A.  BACKGROUND 

The  foundation  of  functional  programming  Ilea  In  the 
notion  of  general  recuralve  functions,  which  can  express  any 
computable  function  CRef.  20:  pp.  1-83.  McCarthy's  “pure" 
LISP  first  illustrated  thia  concept  by  showing  that  a  number 
of  significant  programs  could  be  expressed  as  pure 
functions.  These  pure  functions  in  LISP,  of  course,  operate 
on  list  structures,  but  the  notion  may  be  generalized  to 
other  structures. 

The  importance  of  the  recursive  function  concept  is  the 
impact  that  it  has  on  the  nature  of  programming.  In 
conventional  languages  imperative  statements  are  used  to 
alter  control  flow  and  update  memory.  These  statements  (as 
mentioned  in  chapter  2)  are  dependent  upon  the  order  in 
which  they  are  executed.  The  recursive  use  of  pure 
functions  eliminates  the  requirement  for  these  imperative 
statementa  and,  as  a  result,  is  often  called  “assignment- 
less"  or  "variable- less"  programming.  This  “value-oriented" 
program-ming  is  based  upon  the  use  of  pure  expressions 
(discussed  below)  and  offer a  the  advantages  of  arithmetic 
and  algebraic  expressions  to  the  programming  language  CRef. 
20:  p.  1-13. 
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Probably  on*  of  tha  moat  critical  attacks  upon  tha 
convantional  programming  languagaa  of  tha  von  Nauaann  atyla 
caaa  from  Backus'  Turing  Award  Lecture,  whara  ha  dascrlbaa 
thas  as  “fat  and  flabby”  CRaf.  3:  p.  6143.  His  criticism  of 
tha  framework,  tha  "word-at-a-time“  programming,  and  tha 
lack  of  usaful  mathematical  propartias  of  convantional 
programming  languages  CRaf.  3:  p.  6173  lad  to  tha  design  of 
his  Functional  Programming  <FP)  System. 

An  important  contribution  in  Backus'  FP  paradigm  is 
tha  emphasis  on  tha  use  of  functionals  (described  below) . 
The  use  of  functionals  allows  the  programmer  to  raise 
himself  above  the  recursive  nature  of  the  function  by 
providing  a  higher  level  of  abstraction.  At  this  higher 
level,  the  programs  can  be  made  more  understandable  and 
thereby  much  easier  to  maintain. 

B .  EXPRESSIONS 

Expressions  may  be  arithmetic,  relational,  or  boolean, 
as  illustrated  in  Figure  3.1.  In  conventional 


arithmetic: 
relational : 
boolean: 


(a  ♦  b)  »  c 
a  ♦  b  »  0 
- (a  V  b> 


Figure  3.1  Types  of  Expressions 


m  *  -*  1  ^  ■- 
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languages  thasa  types  of  expressions  appear  on  the  right- 
hand  side  of  an  assignment  stateaent.  By  eliminating  the 
use  of  the  assignment  statement  we  can  concern  ouraelvea 
with  “pure"  expressions  and  the  properties  associated  with 
them  [Ref.  27:  p.  283 .  These  properties  are  listed  in 
Figure  3.2  and  several  are  discussed  below. 


•  value  is  independent  of  the  evaluation 
order 

«  referential  transparency 

•  no  aide  effects 

•  inputs  to  an  operation  are  obvious  in 
the  written  form 

•  effects  of  an  operation  are  obvious  in 
the  written  form 


Figure  3.2  Properties  of  Pure  Expressions 

i.  EzaliuAlan  Ordmr  InfltMadtnsi 

An  important  property  of  pure  expressions  is  the 
fact  that  within  a  given  context,  an  expression  has  the  same 
value  regardless  of  the  order  in  which  it  is  evaluated.  In 
fact,  the  evaluation  of  subexpressions  within  a  given 
expression  will  not  effect  the  evaluation  of  other 
subexpressions,  and  the  order  in  which  they  are  evaluated 
will  not  alter  the  final  value  of  the  overall  expression. 
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The  importance  of  context  can  ba  illustrated  by  an 
MlapuraM  axpraaaion,  aa  In  figura  3.4,  whara  aaaignaanta  to 
variablaa  can  ba  aada.  If  aaaory  outaida  tha  contaxt  ia 
allowad  to  ba  altered,  than  tha  axpraaaion  ia  not  "pure"  and 
aida  af facta  can  raault.  In  thia  caaa  tha  valua  of  tha 
variabla  “a**  can  ba  altarad  by  tha  avaluation  of  tha 
function  call. 


a  ♦  b  »  F(c> 

whara  F(z:integer> :  intagar 
bag  in 
a  :■  0; 

F  *  z  •  z 
and; 


Figura  3.4  lapura  Expraaaion 


2.  RaitrgoUflJ,  TranaBflrtncY 

Tha  proparty  that  tha  raplacaaant  of  an  axpraaaion 
(or  subexpression)  by  ita  valua  ia  antiraly  indapandent  of 
tha  aurrounding  axpraaaion  in  which  it  occura  is  called 
rafarantial  tranaparancy  CRef.  20:  p.  1-33.  Thia  property 
aaana  that  having  evaluated  an  axpraaaion,  it  need  not  be 
evaluated  again.  Thia  provides  tha  universal  ability  to 
substitute  equals  for  equals  within  a  given  context. 


For  example,  given  tha  contaxt  b*3  and  c*4  for  the 
axpraaaion  in  Figura  3.5,  rafarantial  tranaparancy  means 


the 


that  having  avaluatad  <b  ♦  c>  to  tha  nuabar  7, 
aubatitution  of  7  for  tha  othar  oceuranea  of  (b  ♦  c)  will 
not  affaet  tha  valua  of  tha  ovarall  axpraaaion. 


/\ 

/  \ 

/  \ 

/  \ 

m  » 

/\  /\ 

/  \  /  \ 

/  \  /  \ 
a  ♦  d  ♦ 

/\  /\ 

/  \  /  \ 

/  \  /  \ 
b  c  b  c 

(a  *  (b  ♦  c)>  *  <d  »  <b  ♦  c>> 


Figura  3.9  Pura  Expression  aa  a  Traa 


C.  FUNCTIONS 

Nathaaatical  mappings  from  inputs  to  outputs  ara  ''pure'’ 
functions.  Such  pura  functions  ara  tha  and 

oparators  of  tha  pura  axpraaaion  in  Figure  3.4.  The  results 
of  these  operations  depends  only  upon  tha  inputs.  In  fact, 
tha  notions  of  pure  expressions  and  pure  functions  form  an 
interesting  dependency.  In  order  for  an  expression  to  be 
pura  <thua  having  the  properties  stated  above)  it  must 
consist  of  pura  functions.  Additionally,  if  functions  can 
be  constructed  with  pura  expressions  (containing  no 
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AAl  .v  a  ■ 


-■ 


explicit  or  hiddon  aaaignaent  atateaenta) ,  then  the 
function  will  retain  the  propertiea  of  pure  expreaaiona 


(Ref.  20:  p.  1-51. 

1.  Function  Application 

An  applicative  prograa  takea  the  fora  of  an 
expreaaion  that  conaiata  of  the  application  of  pure 
functiona  to  their  arguaenta.  Thua  function  application  ia 
the  fundaaental  operation  of  applicative  prograaaing  and  ia 
illuatrated,  in  Figure  3.6,  by  the  prefix  function  fora  of 
the  expreaaion  in  Figure  3.3. 


tiaeaC (tiaea(plua(b,c) ,a) > , (tiaea(plua(b,c> ,d>  >  > 


Figure  3.6  Prefix  Fora 

Within  the  applicative  prograaaing  language 
functiona  aay  be  defined  explicitly,  conditionally, 
recuraively,  or  aa  the  coapoaition  of  other  functiona.  The 
iaportant  point,  however,  ia  that  theae  functiona  operate 
only  on  data  (charactera,  nuabera,  etc.). 

2.  Functlonala 

In  order  to  provide  a  higher  level  of  abatraction, 
functlonala  are  functiona  that  take  other  functiona  aa 
arguaenta.  Functlonala  reault  froa  identifying  recurring 
petterna  in  function  definltiona  and  abatracting  them  to  a 


higher  level.  The  "»ap“  functional  le  an  excellent  example 


since,  it  accepts  functions  auch  aa  "tinea'',  "plus",  etc. 
and  nape  them  onto  a  list  of  ordered  pairs.  Such  a 
functional  eliminates  the  requirement  to  explicitly  define 
"map.tlmea”,  "map_plus",  etc.  functions. 

Functional  programming,  then,  is  a  form  of  applica¬ 
tive  programming  that  makes  extensive  use  of  functionals. 
Not  only  does  it  simplify  the  programming  process  (fewer 
explicitly  defined  functions),  but  also  offers  additional 
properties  which  are  listed  in  Figure  3.7  CRaf.  27:  p.  301. 


•  easy  to  use  existing  functions  to  build 
new  ones 

•  easy  to  combine  functions  using  composition 

•  subject  to  algebraic  manipulation 

•  easier  to  prove  correct 

•  easier  to  understand 


Figure  3.7  Properties  of  Functional  Programs 

D.  PROOF  OF  CORRECTNESS 

The  mathematical  properties  of  functional  programming 
lend  themselves  to  much  more  straightforward  proof  of 
correctness  than  either  imperative  languages  or  logic-based 
languages.  Most  often,  the  recursive  function  definitions 
of  the  functional  program  can  be  individually  proved  by 
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induction.  Additionally,  tha  functional  programs  themselves 
ara  subject  to  algabraic  manipulation.  A  datailad  analysis 


of  such  algabraic  propartias  is  prasantad  in  Backus'  Turing 
Award  Papar  CRaf .  33 . 

A  comparison  of  Hoare'a  axiomatic  modal  of  correctness 
CRaf.  283  with  that  of  Mill's  functional  model  of 
correctness  CRaf.  293  helps  to  illustrate  this  more 
straightforward  proof  of  correctness  method. 

1.  Hoara's  Axiomatic  Modal 

Hoara's  axiomatic  modal  of  correctness  uses  the 

notation 

(P)  S  (0) 

to  state  the  required  connection  between  the  input  assertion 
P,  output  assertion  Q,  and  the  program  (or  part  of  a 
program)  S.  Partial  correctness  of  program  S  results  if  and 
only  if  for  every  substitution  of  values  which  makes  P  true, 
then  after  execution  of  S,  Q  must  be  true.  Total  correct¬ 
ness  results  if  it  is  proven  that  if  P  is  true  then  S 
terminates  CRef .  213 .  Hoare's  rules  of  inference,  very 

similar  to  the  rules  of  predicate  logic,  are  used  to  prove 
correctness  of  particular  programs.  By  assuming  the  pre- 
and  postassertions  of  every  program  statement,  as  well  as 
the  program  itself,  the  rules  of  inference  are  used  on  each 
piece  of  the  hierarchy  to  establish  the  proof.  The  problems 
arise  from  the  fact  that  most  statements  of  a  program  do  not 
annotate  their  pre-  and  postconditions  and  that  the  proof  of 
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iterative  portion*  of  th*  program  requires  recognition  of  a 
"loop  invariant"  that  i*  of tan  difficult  to  aacertain. 
CRaf.  213. 

2.  Mill'*  Functional  Modal 

Mill 'a  functional  aodal  of  corractnaaa  atates  the 
intandad  function  of  a  program  aa  a  functional  abstraction 
which  aumaarizaa  tha  outcoaaa  of  tha  program  (or  part  under 
consideration) .  Thia  functional  abatraction  ia  independent 
of  tha  control  structures  and  data  operations  and  reduces 
tha  question  of  corractnaaa  to  one  of  function  composition 
and  function  equivalence  [Ref.  213.  Partial  correctness  of 
program  S  means  that  "with  respect  to  function  F,  every 
argument  X,  for  which  F  is  defined  and  F(X)=Y,  then  if 
program  S  ia  executed  with  initial  input  vector  X,  its  final 
output  vector  is  Y."  Total  correctness  is  proven  by  showing 
that  if  X  ia  in  the  domain  of  F  then  S  terminates  [Ref.  213 . 
The  problem  of  determination  of  the  loop  invariant  is 
minimized  since  the  intended  function  of  the  loop  may  be 
easily  converted  to  a  loop  invar iant .The  problem  still 
remains  that  in  most  conventional  programming  languages  most 
atatementa  of  the  program  do  not  annotate  their  function. 

E.  ADVANTAGES 

!•  Higher  Level  of  Abstraction 

The  advantages  to  be  gained  by  functional  program¬ 
ming  are  somewhat  analagoua  to  the  advantages  of  structured 
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programming.  Thm  highar  laval  of  abstraction  affordad  by 
"goto-less"  programming  makaa  it  aaaiar  to  reason  about  and 
understand  programs.  The  gotos  exist  at  a  lower  level  of 
abstraction  and  the  programmer  is  not  burdened  with  those 
details.  Similarly,  the  "assignment-less"  property  of 
functional  programming  encourages  an  even  higher  level  of 
abstraction,  providing  a  more  systematic  derivation  of 
programs  and  resulting  in  greater  understandabillty 
CRef.  20:  p.  3-43.  Assignments,  of  course,  exist  but  are 
hidden  from  the  higher  level  of  abstraction. 

Additionally,  the  functionals  within  the  language 
provide  a  mechanism  for  achieving  an  even  higher  level  of 
abstraction.  Common  patterns  among  user-defined  functions 
can  be  abstracted  out,  named,  and  thereafter  referred  to 
without  concern  for  the  underlying  function  composition. 

2.  H<? 

Many  of  the  side  effects  associated  with  imperative 
programs  result  from  the  assignment  statement  and  its  use  in 
altering  variables  <local  and  non-local) .  This  results  in 
hidden  interfaces  within  the  program,  which  degrade  both 
program  correctness  and  understandability .  In  functional 
programming  the  assignment  statement  is  eliminated  and  the 
Interfaces  manifest  themselves  in  the  expressions  of  the 
program.  This  means  that  the  input-output  connections  of 
the  subexpressions  within  an  expression  are  visually  obvious 
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CRef.  20:  p.  1-43  and  confar  no  hlddan  interfaces  or  side 
effects . 


3.  Verification  and  Proof  Techniques 

The  functional  model  has  several  advantages  over  the 
axiomatic  approach.  By  stating  specifications  and  sub- 
specifications  as  functions  from  an  input  space  to  an  output 
space,  the  functional  model  is  a  mathematical  model  in  the 
strictest  sense.  The  axiomatic  approach  organizes  such 
specif ications  into  Boolean  functions  represented  by 
assertions  on  program  variables,  assertions  given  in  terms 
of  the  relationship  of  the  variables  involved.  The 
functional  approach  is  in  terms  of  the  relationship  of  the 
two  value  seta  involved.  This  means  that  the  axiomatic 
approach  maps  from  the  current  values  of  the  variables  into 
the  two-tuple  CTrue,  False]  instead  of  the  more  mathematical 
functional  model  which  maps  from  the  input  value  space  to 
the  output  value  space.  Another  advantage  is  that  changes 
in  a  program  that  do  not  affect  another  program  segment  do 
not  require  a  new  proof  of  correctness  for  that  segment. 
This  results  from  the  fact  that  the  proof  of  a  functional 
specification  is  in  terms  of  the  behavior  of  the  program 
statement  independent  of  the  history  of  variables  in  the 
segment.  The  assertions  of  the  axiomatic  approach,  however, 
are  reatricted  by  variable  history  and  interdependence  with 
other  variables  CRef.  213.  Additionally,  different 
implementations  of  a  particular  specification  can  be 


38 


substituted  without  requiring  new  proofs  of  other  program 

segaents. 

Functional  programming  and  the  functional  model 
described  go  hand-in-hand  toward  meeting  the  goals  of 
structured  programming.  The  decomposition  of  the  larger 
programming  structure  into  simpler  structures  (stepwise 
refinement)  is  easily  afforded  with  functional  programming 
in  which  larger  programs  or  functions  are  merely 
compositions  of  simpler  functions.  The  problem  mentioned 
above  regarding  conventional  languages  and  how  each 
statement  rarely  annotates  its  function  is  eliminated  with 
functional  programming.  Therefore.  the  functional  program 
lends  itself  to  proof  of  correctness  with  the  discussed 
model  in  a  convenient  manner. 

4 •  Parallelism 

The  ability  to  perform  parallel  execution  in 

functional  programming  is  a  direct  result  of  the  property  of 
evaluation  order  independence  inherited  from  pure 
expressions.  The  various  nonoverlapping  subexpressions 
within  an  expression  can  be  evaluated  simultaneously  since 
the  evaluation  of  one  is  not  dependent  upon  the  evaluation 
of  another.  Therefore,  a  multiprocessor  could  assign 
various  proceasora  to  evaluate  different  parts  of  an 

expression  in  parallel. 


Unlike  conventional  languages  which  require  the 
programmer  to  identify  the  portions  of  a  program  which  can 


V.  FEATURES  OF  AH  INTEGRATED  LANGUAGE 

A.  SYNTAX  ISSUES  DEFERRED 

Whether  the  syntax  of  an  integrated  language  should  be 
uniform  (either  functionally  based  or  logically  based),  or 
whether  it  should  be  mixed,  is  an  issue  that  will  be 
deferred  at  this  point.  The  intention  is  to  describe  the 
important  features  of  an  integrated  language  and  discuss  the 
modifications  required  of  the  resolution  process  within  the 
declarative  component.  In  keeping  with  the  examples  of  the 
previous  chapter,  the  use  of  PROLOG  and  LISP  syntax  can 
adequately  represent  the  points  to  be  made,  and  the  mixed 
syntax  will  better  illustrate  the  transfer  of  control  from 
procedural  interpretation  to  declarative,  and  vice  versa. 

With  this  transfer  in  mind,  the  ”#"  symbol  will 
represent  the  transfer  of  control  from  one  component  to  the 
other.  The  results  from  a  procedural  call  (function 
application)  within  the  declarative  component  must  be  the 
value  of  the  evaluated  function,  and  will  be  used  to 
instantiate  (or  unify)  a  variable  within  the  clause.  The 
results  from  a  declarative  call  (resolution  process)  within 
the  procedural  component,  on  the  other  hand,  must  return  a 
list  of  solutions  to  the  query.  Each  solution  is  itself  a 
list  of  variable  bindings  that  provide  a  solution  to  the 
given  query. 
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the  previous  cxaiplt: 

Queries  (call*  to  tha  daclarativa  coaponant)  auat  be 
qualified.  Qualification*  auch  aa  'all',  'any',  etc. 
auat  be  aade  explicitly  in  the  query. 

Unification  auat  be  baaed  upon  the  given  context  (or 
environaent)  in  which  the  declarative  call  is  aade.  A 
context  ia  a  list  of  unificationa  (or  bindings)  which 
provide  a  constraint  upon  the  resolution  of  the 
declarative  clause. 

These  observation*  fora  the  foundation  upon  which  the 
features  of  a  truly  integrated  language  can  be  described. 
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(defun  append  (  L  M  ) 


(cond 

((  null  L>  H  ) 

<T  (cons  (car  L>  (append  (edr  L>  M  > )  ) )  ) 

appand  (  #(weekly_Tax(X, 30> ,  waakly_tax( Y,30> ) , 
' (John  Smith)  > 


Figure  4.4  Call  to  Declarative  Component 

the  procedural  component  expecta  the  declarative  call  to 
return  a  liat  of  employeea  which  pay  30  dollars  in  weakly 
tax.  However,  auppoae  the  uninatantiated  variable  Z  was  in 
place  of  the  30.  The  resulting  list  of  employees  would  be 
dependent  upon  the  various  instantiations  of  Z,  and  without 
knowing  which  employees  were  associated  with  those  values  of 
Z,  the  resulting  list  would  be  meaningless.  What  about  a  3- 
tuple  list  which  yields  the  X,  V,  and  Z  instantiations  of 
every  solution?  Such  a  liat  could  become  a  rather  large 
list  of  permutations  with,  possibly,  redundant  information. 
Here  the  results  to  be  returned  are  more  complicated  and 
require  modification  to  the  resolution  mechanism  within  the 
declarative  interpreter. 

Such  modification,  discussed  in  the  following  chapter, 
is  based  upon  two  important  observations  that  arise  from 


31 


advantages  gained  by  backtracking  within  a  single  clause 
become  cumbersome,  tedious,  and  expensive  when  backtracking 
must  occur  through  several  clauses  that  have  the  same  head. 
In  sn  integrated  approach,  the  ability  to  define  weekly_tax 
(Figure  4.3)  with  a  procedural  call  (denoted  by  the 
symbol),  which  performs  the  conditional  control,  allows  the 
instantiated  values  of  the  variables  Z  and  B,  unified 
through  resolution,  to  be  used  in  the  function  to 
Instantiate  the  variable  Y.  The  requirement  for  three 
clauses  with  the  same  head  has  been  reduced  to  one  clause 
where  resolution  is  no  longer  needlessly  replicated. 

In  such  an  example,  note  that  the  functional  call 
from  the  declarative  component  merely  returns  the  value  of 
the  evaluated  function.  Such  a  function  can  be  evaluated  by 
theprocedural  interpreter  and  is  regarded  as  a  standard 
functional  expression. 

2.  Declarative  Call  From  Procedural  Component 

A  call  to  the  declarative  component  from  the 
procedural  component,  on  the  other  hand,  requires  a 
rethinking  of  the  resolution  process.  For  example.  Figure 
4.4  illustrates  such  a  call  in  an  attempt  to  use  the 
advantages  of  resolution,  instead  of  explicitly  defining  a 
function,  to  search  the  knowledge  base  and  perform  the 
unifications  which  provide  a  solution.  But  in  this  case  the 
call  to  the  declarative  component  cannot  merely  return  the 


result  of  an  evaluated  expression 


In  this  simple  example 


to  Kowalski's  concspts  (described  in  chapter  2)  of  separa¬ 
tion  of  logic  and  control,  and  LUSH  resolution  of  Horn 

clauses . 

In  keeping  with  these  concepts,  a  procedural  component, 
namely  functional  programming,  can  provide  the  control 
characteristics  for  an  effective  and  efficient  declarative 
component,  as  well  as  provide  a  means  for  representing  non- 
declsrative  knowledge. 

1 .  Procedural  Call  From  Declarative  Component 

To  illustrate  this  notion,  consider  first  the 
ability  to  call  the  procedural  component  from  the 
declarative  component.  For  example,  the  logic  program  In 
Figure  4.1  used  three  clauses  to  define  weekly_tax.  The 


weekly _tax(X,Y)  <--  weekly.salary (X,B> , 

annual_salary (X,Z> , 

Y  is  #(COND 

( (GEO  20000  Z) 

(TIMES  .06  B) 

( (GEQ  10000  Z) 

(TIMES  .04  B) 

(T  (TIMES  .02  B)  >>  )> 


Figure  4.3  Call  to  Procedural  Component 


clause  yielding  X  ■  C]  and  Y  ■  Ca,b,c3 .  Tha  cut  would 
prevent  any  further  resolution  and  no  other  answers  could  be 
generated  even  though  othera  existed  CRef.  2:  pp.  65-663. 
As  the  cut  ia  placed  deeper  in  the  body  of  a  clause,  to 
freeze  unification  made  to  that  point,  the  aide  effecta 
become  more  difficult  for  the  programmer  to  predict. 

In  an  attempt  to  provide  a  meana  of  controlling  the 
coat  of  backtracking,  the  PROLOG  implementation  of  logic 
programming  requirea  the  programmer  to  be  aware  of  the 
underlying  backtracking  mechaniam,  introducea  poaaible  side 
effecta,  and  negatea  the  advantage  gained  by  keeping  the 
reaolution  mechaniam  at  a  lower  level  than  that  of  the 
programmer . 

C.  INTEGRATION 

The  previoua  examples  help  to  illustrate  certain 
problems  and  inadequacies  that  result  from  either  a  strictly 
procedural  approach  to  programming,  or  from  a  declarative 
approach  interspersed  with  procedural  features  for  efficient 
control.  The  PROLOG  implementation  of  logic  programming  is 
a  somewhat  integrated  approach,  though  to  a  very  small 
degree,  and  the  major  problems  with  that  approach  have  been 
described.  The  existence,  and  utility,  of  PROLOG  gives  some 
credence,  then,  to  the  feasibility  of  an  integrated 
language.  However,  the  problems  with  PROLOG  seem  to  stem 
from  the  features  of  the  language  which  are  somewhat  foreign 
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programming  that  offars  thia  abatraction  alao  raquiraa  tha 
uaa  of  tha  "cut**  ayabol.  Tha  cut  ayabol  ia  a  aaana  of 
halting  unnacaaaary  or  unwanted  backtracking.  Zta  uaa 
within  tha  clauaaa  of  a  logic  prograa  raquiraa  tha 
prograaaar  to  ba  intiaataly  familiar  with  tha  aathod  of 
backtracking,  or  aida  af facta  aay  ba  introduced  into  the 
prograa.  Thia  ia  bacauaa  tha  cut  ayabol  altera  tha  way 
backtracking  worka  after  ita  uaa.  Tha  affect  of  the  cut  ia 
to  remove  tha  place  aarkara  for  certain  goala  ao  that  they 
cannot  ba  reaatiafiad,  and  coaaita  tha  ayatea  to  every 
unification  aade  aince  that  clauae  waa  entered  CRef.  2:  pp. 
64-681  . 

The  aida  affacta  of  uaing  the  cut  ayabol  ariae  from 
the  fact  that  a  clauae  aay  ba  uaed  in  a  aanner  for  which  it 
waa  not  intended.  For  inatance,  conaidar  the  two  clauses: 
append (  Cl  ,  X,X)  <—  "cut". 

'  append < CA I B1 ,C, CA I D1 )  <--  append(B,C,D) . 
where  tha  cut  pravanta  unnacaaaary  backtracking.  Whan 
raaolving  goala  Ilka 

< - -  append < £a,b, cl , Cd, al ,X> 


or 


<--  append < Ca,b,cl ,X, Y) 

tha  cut  worka  aa  intended  and  ia  appropriate  from  an 
efficiency  atandpoint.  However,  if  tha  goal 

<--  append<X, Y, Ca,b,cl ) 


ia  raaolvad,  it  would  ba  matched  and  unified  with  tha  firat 


without  defining  «  nested  function  thet  explicitly  checks 
the  detsbsse  sgsinat  e  conditional  expreaaion  and  conatructa 
a  new  list  with  the  reaulta. 


Figure  4.2  LISP  Program 


This  illustrates  that  the  pattern  matching  in 
PROLOG,  resulting  from  the  resolution  of  subgoals,  ia  an 
advantage  during  the  search  of  the  database,  because  the 
method  of  search  ia  at  a  lower  level  than  that  of  the 


program , 


However,  the  same  PROLOG  implementation  of  logic 


il  l  *  ’  V  « 


m 


V,’,,  t  V  L  ■  *  C,  O’-vl  *  *,  Ca'.*  ' 


v.-v: 


by  on*  function  (with  a  conditional)  in  tha  functional 
program,  both  prograaa  parfora  tha  aaaa  function  and  thalr 
dlffaranca  ia  priaarily  syntactical. 


waakly_salary< John_Doa,500) . 
waakly_aalary(Jia_Jonas,350) . 

a 

a 

a 

annual_aalary (X, Y)  <--  waakly_aalary <X,Z) , 

Y  ia  (Z  •  48) . 

waakly_tax(X,Y)  < —  annual_aalary (X, Z) ,  Z  >=  20000, 

waakly.aalary <X,B> , 

Y  ia  <B  •  .06). 

waakly_tax(X, Y)  < —  annual_aalary (X,Z> ,  Z  >»  10000, 

Z  <  20000,  waakly_salary <X,B> , 

Y  ia  (B  •  .04) . 

waakly_tax(X, Y)  < —  annual  ..salary <X,Z) ,  Z  <  10000, 

waakly.aalary <X,B) , 

Y  ia  <B  »  .02). 


Figura  4.1  PROLOG  Program 


Howavar,  a  quary  to  tha  logic  program  much  aa 
< - -  waakly_tax(X, Y) ,  waakly_tax(Z, Y)  , 
which  will  raturn  all  pairs  of  amployaaa  that  pay  tha  same 
waakly  tax,  la  not  poaaibla  in  tha  functional  program 


•uch  instance*  it  ia  not  only  unnatural  to  define  thea 
declaratively ,  it  ia  leaa  efficient  CRef.  253. 

By  contrast,  the  non-declarative  aspect  of  functional 
programming  can  make  the  manipulation  of  information  in  a 
knowledge  base  very  tedious  and  inconvenient.  Since  the 
search  of  such  a  knowledge  base  is  explicit,  the  programmer 
must  define  functions  that  perform  the  search  or  comparisons 
required.  These  contrasting  aspects  of  both  programming 
paradigms  will  be  illustrated  and  explained  in  the  following 
examples. 

B.  EXAMPLES  OF  CONTRAST 

1 .  Declarative  Versus  Procedural 

Consider  the  PROLOG  program  in  Figure  4.1  and  the 
LISP  program  in  Figure  4.2.  The  program  in  figure  4.1  can 
be  used  to  find  out  such  information  as  the  annual  salary, 
weekly  tax,  etc.  of  an  employee  asserted  in  the  database. 
By  merely  satisfying  the  goal 

< - -  weekly_tax( John_Doe,  X) 

the  system  will  perform  the  necessary  resolution, 
backtracking  and  unification  to  produce  the  weekly  tax  of 
John  Doe.  Similarly,  the  LISP  program  in  Figure  4.2  will 
return  that  individuals  weekly  tax  when  the  function 

weekly_tax  < John_Doe> 

is  called.  In  comparison,  not*  that  although  the  three 


clauses  for  weekly  tax  in  the  logic  program  can  be  defined 


A.  PROCEDURAL  AND  DECLARATIVE  COMPONENTS 


Having  described  both  tha  logic  progressing  and 
functional  prograaalng  paradigas,  wa  now  conaidar  tha 
faaaibility  of  a  language  which  integrataa  aoaa  of  the 
features  of  both  prograaalng  paradigaa.  It  should  be  noted 
here  that  both  logic  prograaalng  and  functional  prograaalng 
are  within  a  classification  of  prograaalng  which  MacLennan 
refers  to  as  "value-oriented"  progressing  [Ref.  22] .  He 
includes  equational  prograaalng  CRef.  23]  and  relational 
prograaalng  as  wall  CRef.  24],  but  here  we  consider 
equational  prograaalng  a  sore  restrictive  fora  of  functional 
prograaalng  and  relational  prograaalng  a  fora  of  functional 
prograaalng  (since  a  function  is  a  relation)  which  can  deal 
with  aulti-valued  functions.  The  focus,  then,  is  on  the 
feasibility  of  integrating  a  procedural  coaponent 
(functional  prograaalng)  and  a  declarative  coaponent  (logic 
progressing)  within  a  single  language. 

The  non-procedural  aspects  of  logic  progressing  sake  it 
very  advantageous  for  stating  facts  (or  axioas)  froa  which 
knowledge  can  be  inferred,  or  about  which  queries  can  be 
aade.  Yet  it  is  unnatural  to  define  everything 
declaratively .  For  exaaple,  aost  PROLOG  iapleaentations 
define  nuabera  and  the  operations  on  thea  procedural ly.  In 
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•valuation  ord«r  independence,  lands  itself  to  parallel 
execution  in  a  aulti -processor  anvironaant. 

Tha  diaadvantagaa  of  tha  functional  prograaaing  paradiga 
raat  with  its  soaawhat  liaitad  problaa  doaain,  bacausa  of 
its  waaknass  in  raprasanting  taaporal  ralationships. 
Although  functional  languagas  land  thaasalvas  to  parallel 
execution,  without  aora  effective  use,  in  teraa  of  hardware 
support,  of  the  parallel  nature  of  the  language,  the  coat  of 
nuaeroua  recursive  calls  is  inefficiency. 


Unfortunately,  such  multiprocessor  support  for  functional 
languages  is  not  widespread  and  the  use  of  such  a  language 
as  “pure”  LISP  on  a  uniprocessor  can  be  very  slow  depending 
upon  the  nested  levels  of  recursion.  Without  the  support 
for  parallel  execution,  efficiency  can  quickly  become  a 
major  factor  in  the  ef f ectiveness  of  the  programming 
language. 

3.  Industry  Resistance  to  Change 

As  with  most  new  concepts,  the  resistance  to  change 
surfaces  whenever  the  status  quo  is  threatened.  Host  of 
industry  is  still  tied  to  the  von  Neumann  architecture  and 
“mind  set"  (both  financially  and  intellectually).  Until  the 
decisionmakers  within  the  industrial  complex  are  convinced 
that  the  advantages  afforded  by  new  concepts  will  outweigh 
the  expenditure  in  time,  personnel  training,  and  money, 
these  new  concepts  will  remain  at  the  theoretical  or 
experimental  level . 

G.  SUMMARY 

The  functional  programming  paradigm  provides  the 
programmer  with  a  very  high  level  of  abstraction,  making  it 
easier  to  reason  about  and  understand  programs.  In  contrast 
to  von  Neumann  languages,  functional  languages  are  free  from 
side  effects  resulting  from  heavy  dependance  upon  the 
assignment  statement.  Additionally,  the  non -sequential 


nature  of  functional  programming,  baaed  upon  the  property  of 


be  run  concurrently*  a  functional  language  can  handle  aa 
many  processors  aa  there  are  aubexpreaaiona  to  evaluate*  and 
tih#  order  in  which  the  proceaaora  are  aaaigned*  or 
aubexpreaaiona  are  evaluated  will  not  alter  the  final 
evaluation  (it  aay*  of  courae*  affect  the  efficiency  of 
execution) . 

F.  DISADVANTAGES 

1.  Limited  Problea  Dona in 

Although  the  mathematical  propertiea  of  functional 
programming  offer  advantages*  certain  tradeoffs  do  result 
from  those  properties.  Theae  tradeoffs  have  a  limiting 
effect  upon  the  problem  domain  to  which  functional 
programming  solutions  are  practical*  or  even  feasible. 

Functional  programming  provides  no  notion  of  state 
nor  does  it  provide  any  notion  of  time.  This  weakness  in 
maintaining  temporal  relations  restricts  the  use  of 
functional  programming  for  such  state-oriented  applications 
aa  operating  systems,  database  management*  or  discrete 
simulation . 

2 .  Recursion  and  Inefficiency 

The  recursive  function  definition  is  an  important 
component  within  a  functional  programming  language  and  is 
probably  the  most  expensive.  The  expense  of  numerous 


recursive  calls  can  be  minimized  if  the  hardware  support  can 
taka  advantage  of  the  parallelism  afforded  by  the  language. 


B.  QUALIFICATION  OF  A  QUERY 

A*  described  in  the  previous  chapter,  a  call  to  tha 
declarative  component  must  be  qualified  to  ensure  that 
expected,  and  meaningful,  reaulta  are  returned  to  the 
procedural  component.  In  general,  the  programmer  may 
require  several  different  types  of  results  from  the 
declarative  component.  In  some  Instances  the  programmer  may 
require  a  list  of  all  possible  solutions  to  a  given  query. 
But  in  other  instances,  the  programmer  might  require  only  a 
limited  number  (or  even  one)  of  all  the  possible  solutions. 

Based  upon  the  functions  described  in  Robinson's  LOGLISP 
[Ref.  261  these  qualifiers  can  be  represented  by  the 
following: 

ALL  -  returns,  as  a  result  of  the  declarative  call,  a 
list  of  all  tuples  which  satisfy  the  query  within 
the  constraints  of  the  current  context  (details  of 
resolution  within  a  context  are  in  a  later  section). 

ANY  K  -  returns  a  list  with  no  more  than  K  of  the  tuples 
returned  by  ALL. 

With  these  two  qualifiers  as  the  foundation,  the 
programmer  may  use  the  functional  component  of  the  language 
to  define,  for  convenience,  functions  which  perform  special, 
or  redundant,  cases  of  the  basic  qualifiers.  For  example, 
the  qualification  ANY  1  to  the  given  goal  statement,  will 
return  a  list  containing  the  single  list  of  variable 


bindings  that  provides  one  solution.  A  function  THE,  which 


will  return  those  bindings  in  a  single  list,  and  say  be 


defined  by 


THE  <Q>  -  #ANY  1  (0) . 


C.  QUERIES  AND  THEIR  CONTEXT 

Associated  with  each  query,  or  goal  atatenent  to  be 
resolved*  is  an  isplicit  context  within  which  certain 
constraints  are  placed  upon  the  resolution  process.  These 
constraints  are  variables  which  are  already  bound  to  values. 
If  variables  that  are  part  of  the  goal  statement  are  already 
bound,  then  those  variables  cannot  be  re- instantiated  during 
the  resolution  process.  For  those  variables  that  are  not 
defined  in  the  current  context  of  the  query,  they  are 
considered  free  variables  and  can  be  instantiated  (or  bound) 
during  the  resolution  process. 


The  context  associated  with  each  query  contains  all 
bound  variables,  of  local  scope,  which  may  be  bound  to  terms 
or  to  other  variables.  The  fact  that  variables  may  be  bound 
to  other  variables  makes  the  unification  somewhat  more 
complicated,  but  is  necessary  to  allow  the  resolution  of  the 
goal  to  progress  as  intended.  It  should  be  noted,  however, 
that  such  indirect  binding  must  eventually  terminate  with  a 
binding  to  a  term  within  that  context. 

The  bindings  within  a  given  context  can  be  denoted 
in  a  manner  that  lends  itself  to  LUSH  resolution  (see 


Chapter  2>»  which  will  simplify  tha  checking  of  variables 


within  that  context.  For  example* 

X  <--  Y 
Y  <--  a 
Z  <--  b 

repreaenta  the  context  (variables  in  uppercase*  terms  in 
lowercase)  of  a  given  query  Q,  within  which  X  Is  bound  to  Y* 
Y*  in  turn*  is  bound  to  "s'**  and  Z  la  bound  to  “bM. 
Therefore*  a  query  such  as 

P(T,X, V) 

would  have  two  free  variables*  T  and  V*  and  the  variable  X 
would  be  bound  to  the  term  “a"  during  each  resolution 
process  in  the  search  for  a  solution. 

2.  Context  Algorithm 

For  a  given  query  Q  and  its  associated  context  C, 
the  constraints  placed  upon  tha  resolution  of  Q  are 
represented  by  the  variables  that  are  already  bound.  The 
following  algorithm  is  concerned  with  a  query  of  the  form 

QiP^pP^f  ...  f P^) 

where 

P.(X,*X_*  ...  *X  > 

represents  each  predicate*  and  C  is  the  context  of  the 


Algorithm: 


lyl 


for  (each  variable  of  ovary  pradicato  P^  in  Q> 
raaolva  C(X^)  {parfora  LUSH  resolution  on  ) 


(database  C 


ii.  C<X3>  •  nil 


than  X^  ia  a  free  variable  and  do  nothing 
else  instantiate  X^  to  tara  t^,  returned  from 

resolution  of  C(X^),  within  the  query  Q 
place  the  binding  tuple  in  the  list  SQ  that 
will  contain  all  such  bindings 
until  (all  variables  are  checked > . 

Once  these  constraints  have  been  placed  upon  Q,  the 
query  can  then  be  resolved  (subject  to  the  aodif ications 
described  below). 


D.  MODIFICATION  TO  THE  RESOLUTION  PROCESS 

Moat  PROLOG  iapleaentations  provide  for  the  resolution 
of  goal  stateaenta  based  upon  the  LUSH  resolution  described 
in  Chapter  2.  When  a  prograaaer  makes  a  query  to  the 
knowledge  base  and  a  solution  is  provided,  the  programmer 
may  then  induce  a  failure  (usually  by  hitting  return)  which 
invokes  backtracking  in  search  of  another  distinct  solution. 
For  our  integration  purposes,  the  qualifiers  ALL  and  ANY  K 
determines  at  the  outset  whether  one,  more,  or  all  solutions 
are  required. 


From  the  above  context  algorithm,  the  constraints  placed 
upon  tha  query  0  era  dafinad  in  tha  liat  of  bindings  SQ. 
This  liat  contains  tha  instantiatad  variables  of  Q  (if  any), 
and  have  been  so  instantiatad  in  Q.  Tha  query  Q  may  now  be 
resolved  by  tha  declarative  component,  tha  PROLOG 
interpreter  for  this  example,  until  a  solution  is  found  or  a 
failure  is  obtained.  Given  a  solution  is  found,  let  the 
associated  list  of  all  solutions  be  denoted  by 

s  =  <s1,s2,  ...  ,S^, 

where  is  the  first  solution  obtained  in  the  resolution 
process . 

In  constructing  such  a  solution,  the  following  algorithm 
represents  the  modification  to  the  resolution  mechanism  of 
the  declarative  Interpreter  that  will  allow  its 
construction.  The  algorithm  modifies  the  basic  declarative 
interpreter  such  that  the  entire  results  of  the  qualified 
query  are  returned  as  a  liat  of  bindings  which  satisfy  that 
query.  Once  the  declarative  resolution  mechanism  returns  a 
failure,  there  are  no  more  solutions  to  be  obtained,  and  the 
search  is  halted.  If  it  is  the  first  attempt  at  a  solution, 
then  the  empty  list  is  returned,  otherwise  the  list  of 
solutions  to  that  point  are  returned. 

Algorithm : 

Given  the  qualifier  to  the  query,  the  query  Q,  and  the 

constraint  bindings  in  C, 


First  i , 

raoaat 

raaolva  0 

if  FAIL  (froa  resolution  of  0) 
than  if  i  »  1 

than  ■  O 

place  in  S 

HALT; 

tiii  (have  a  aolution) 

place  binding  tuples  of  solution  in  a  list 

(returned  froa  resolution  of  Q) 
append  this  list  to  Sq 

(to  include  initialization  bindings) 
let  denote  new  Hat 
place  in  S 

induce  FAILURE  (standard  PROLOG  aechanisa  to  ) 

(search  for  another  solution  ) 

if  qualifier  *  ANY  K  (check  qualifier) 
then  if  i  >=  K 

then  HALT; 

Next  i 
UflJULl  HALT 
return  S. 

Notice  that  the  binding  constraints  placed  upon  the 
initial  query  aust  be  explicitly  included  with  the  solution 
bindings  resulting  froa  the  resolution  of  0.  These  bindings 


39 


were  saved  in  whan  tha  constraint  instantiations  wars 
aada  in  Q.  Thay  must  ba  returned  as  part  of  solutions  in  S 
since  thay  provide  variable  bindings  that  are  part  of  tha 
solution. 

Although  there  is  no  explicit  check  for  the  ALL 
qualifier  in  the  algorithm,  it  is  felt  that  its  syntactic 
inclusion,  as  part  of  the  qualification  to  the  query,  will 
provide  more  regularity  and  structure  to  the  integration 
interface. 


E.  AN  INTEGRATION  EXAMPLE 

To  illustrate  the  extensibility  offered  the  programmer 
from  the  functional  component,  consider  the  function  in 
Figure  S.l.  This  function  takes  the  list  of  solutions 
obtained  from  the  declarative  call,  represented  by 


S  »  <  S.  S_  . . . .  S  ) 
12  m 


where 


S.  -  <<X.  t, )  <X_  t->  ...  (X  t  >>, 
x  ii  4  4  n  n 

and  allows  the  programmer  to  specify  which  variables  within 
the  declarative  call  will  be  returned  as  meaningful  results. 
This  general  function  provides  the  programmer  considerable 
flexibility  in  utilizing  or  manipulating  the  results 
obtained  from  the  declarative  call. 

For  example,  consider  a  knowledge  base  of  facts 
concerning  the  armed  forces  of  various  countries,  their 
mobilization  status,  geographical  relationships,  etc. 


•>A 

St 

m\ 


Return_liat  *  <<NLAMBDA  L> 

(PROG  (  S  VARLZST  RESULTS  > 

(SETQ  S  (EVAL  (LAST  L>>> 

(SETQ  VARLIST  (LDIFFERENCE  L 

(LAST  L>>> 

(SETQ  RESULTS 

(MAPCAR  S  ' LAMBDA  (Si> 

(MAPCAR  VARLIST  'LAMBDA  (X> 
(ASSOC  X  >>  >>  )> 


Figure  S.l  Function  Definition 
Then  a  question  of  the  fora 

"Which  Warsaw  Pact  countries  have  exercised  armored 
divisions  within  the  past  six  months,  and  what  divisions 
were  they?" 

could  be  handled  by  the  following  function  (which  makes  a 
call  to  the  declarative  component): 

Return_liat  (X  Y  (#ALL  (country (X),  warsaw_pact (X) , 

armored_diviaion(X, Y) , 
aobilize(Y,D> ,  D  >  Z  >>) 

Here  we  assume  that  the  variable  Z ,  representing  a  Julian 
date,  has  been  bound  outside  the  function  call  (perhaps 
based  upon  a  previous  query  regarding  information  within  the 
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V/ 


last  six  months) 


Therefore,  ths  variabls  Z  is  in  ths 


currant  contaxt  C,  is  instant iatad  in  tha  query,  and 
aavsd  in  SQ,  bassd  upon  ths  contsxt  algorithm  describsd 
abova. 

Turning  to  ths  function  in  Flgura  5.1,  tha  solutions 
raturnad  in  S  (bassd  upon  ths  modifiod  resolution  algorithm 
abova)  ara,  in  affact,  associated  with  ths  variables 
explicitly  listed  as  an  argument  to  Return_list,  and  only 
these  values  are  returned.  In  this  case  the  variables  X  and 
Y  are  listed,  and  may  be  exemplified  by  results  such  as 

((Poland  Fifth.armored)  (Poland  Seventh_armored) 
(Hungary  Second.armored)  (DDR  Second_armored) ) . 
Other  queries  can  be  made  to  the  declarative  component 
baaed  upon  the  solutions  provided  by  the  previous  results. 
For  instance,  a  follow-on  question  like 

"Where  is  the  Second  armored  division  of  the  DDR 
currently  located?" 

could  be  resolved  by  first  instantiating  variables  X  and  Y 
outside  the  query  (possibly  using  SETO)  and  using  the 
function  Return_liat  again  with  a  different  call  to  the 
declarative  component.  Therefore,  the  function  call 

Return_liat  (W  (#ANY  1  (armored_diviaion(X, Y)  , 

current_location( Y, W) ) )  ) 

would  return  the  current  location  (given  such  information  is 
in  the  knowledge  base)  of  the  instantiated  armored  division. 
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F.  SUMMARY 


The  praviout  axaaplM  illustrate  the  notion  of  a 
procedural  coaponant  providing  the  control  for  logical 
ralationahipa  in  the  declarative  component  of  an  integrated 
language.  They  deaonatrata  the  concept  of  reaolution  within 
a  context,  deacribed  above,  and  illustrate  the  flexibility 
provided  the  programmer,  in  that  uaer  defined  functions  can 
be  created  to  best  utilize  or  manipulate  the  results 
provided  by  a  query  to  the  declarative  component. 

By  strict  enforcement  of  the  separation  of  logic  and 
control,  the  use  of  the  “cut**  symbol  can  be  eliminated.  Its 
use  in  PROLOG  is  based  upon  the  fact  that  the  programmer  is 
required  to  provide  control  mechanisms  within  the  logical 
relationships  that  are  created.  A  logical  relationship  that 
is  so  complex  that  a  cut  is  used  by  the  programmer  (to 
effectively  save  information  to  that  point  by  halting  the 
backtracking  mechanism)  must  be  simplified  in  a  way  that 
makea  each  logical  relationship  a  separate  entity. 
Therefore,  the  programmer  still  has  the  burden  of 
understanding  the  manner  and  method  with  which  logical 
relationships  are  defined  in  the  declarative  component,  but, 
more  importantly,  the  requirement  to  understand  the  low- 
level  details  of  backtracking  is  removed. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  previous  chapter  described  the  initial  features  to 
be  considered  in  the  integration  of  logic  prograaaing  and 
functional  programming.  Presented  has  been  an  argument  that 
an  integrated  language  better  supports  Kowalski's  notion  of 
separation  of  logic  and  control  CRaf.  S3.  This  argument  has 
been  based  upon  the  idea  that  declarative  sorts  of  knowledge 
(facts  and  logical  relationships)  should  be  expressed  in  a 
declarative  way.  and  that  procedural  sorts  of  knowledge 
(manipulation,  control,  and  utilization  of  data)  ahould  be 
expressed  in  a  procedural  way. 

Toward  this  end.  the  declarative  component  of  an 
integrated  language  establishes  a  knowledge  base  of  facta 
(or  assertions)  as  well  as  rules  for  associating  those 
facts,  determining  logical  relationships  among  them,  or  even 
Inferring  new  knowledge  and  relationships.  The  procedural 
component.  then.  is  the  interactive  tool  for  explicitly 
controlling  those  logical  relationships  and  the  knowledge 
base  of  facts  upon  which  they  are  built. 

The  explicit  control  afforded  by  the  procedural 
component  has  eliminated  redundant  and  unnecessary 
backtracking.  Since  multiple  rules  are  no  longer  required 
to  define  a  single  logical  relationship.  redundant 


backtracking  through  tha  bodiaa  of  aavaral  clauaaa  with  tha 
mm  haad  ia  avoidad.  Thia  allowa  tha  prograaaar  to 
aaaociata  ona  clauaa  with  ona  logical  relationship, 
providing  claarar  undaratanding  and  aaaiar  aodification  and 
aaintananca. 

Tha  nacaaaary  control  for  utilizing  and  manipulating 
raaulta  obtainad  from  a  quary  to  tha  daclarativa  knowledge 
baaa  ia  provided  by  tha  programmer.  Thia  control,  however, 
ia  no  longer  at  tha  low  level  required  whan  uaing  the  “cut" 
symbol.  Tha  control  ia  now  concerned  with  logical 
relationships  and  avoids  tha  side  affects  resulting  from  the 
use  of  tha  “cut". 

Additionally,  tha  programmer  ia  no  longer  concerned  with 
explicitly  defining  tha  search  of  a  knowledge  base  of 
assertions  and  rules.  By  uaing  tha  procedural  component  to 
manipulate  tha  raaulta  obtainad  from  a  query  to  the 
declarative  component,  tha  programmer  can  focus  on  higher- 
level  issues  of  interrelationships  among  tha  results  of  such 
a  quary,  not  on  tha  lower- level  details  of  how  that  search 
was  performed. 

All  of  these  conclusions  support  the  ideas  of 
abstraction,  higher-level  focus,  and  information  hiding, 
discussed  in  Chapters  1  through  4.  The  argument  for  an 
integrated  language,  based  upon  the  features  described  in 
Chapter  9,  is  conceptually  sound,  and  has  further  supported 
the  idea  that  representing  varied  forms  of 


knowledge  in  a  strictly  procedural,  or  strictly  daclarativa, 
manner  forces  tha  prograaaar  to  contort  tha  representation 
of  one  fora  of  knowledge  to  fit  its  expression  in  another 
fora. 

B.  RECOMMENDATIONS 

Having  provided  a  conceptual  fraaework  for  the  design  of 
an  integrated  language,  future  eaphasia  should  be  placed 
upon  aore  detailed  design,  and  eventual  iapleaentation,  of 
each  of  the  procedural  and  declarative  coaponenta  of  the 
language.  A  decision  aust  be  aade  regarding  the  choice  of 
syntax  (unifora  or  aixed)  of  the  language,  and  the  detailed 
features  of  each  coaponent  aust  be  based  upon  that  decision. 
For  instance,  the  choice  of  a  functionally -baaed  uniform 
syntax  would  require  a  redesign  of  the  manner  in  which 
logical  assertions  and  relationships  are  represented  and 
Interpreted.  Such  a  redesign,  however,  say  greatly  simplify 
the  integration  interface  described  in  the  previous  chapter. 

Additionally,  emphasis  must  be  placed  upon  issues  which 
were  of  concern  regarding  each  programming  paradigm  in  and 
of  itself.  Such  issues  are  efficiency  considerations  and 
parallelism.  With  regard  to  efficiency,  both  the  functional 
programming  language  and  the  logic  programming  languages  are 
inherently  alow  without  adequate  hardware  support.  This 
slowness  is  a  reault  of  recursion  in  the  functional  language 


and  Marching  in  tha  logic  language.  Having  an  integrated 
language  with  both  feature*  eephaaizea  the  necessity  for  the 
hardware  support  for  parallel  execution. 

Fortunately,  both  functional  programming  and  logic 
programming  support  the  notion  of  parallel  execution,  and 
with  adequate  hardware  support,  an  integrated  language  could 
provide  the  beat  features  of  a  functionally-baaed  procedural 
component,  as  well  as  the  beat  features  of  a  logically-based 
declarative  component,  and  that  is  sufficiently  efficient  to 
provide  timely  calculations  and  results. 
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